Security Templates

A security template is a file which represents a security configuration. Security templates may be applied to a local computer, imported to a Group Policy object, or used to analyze security.

  • Before proceeding, see Checklist: Securing computers using Security Configuration Manager.
  • For tips about using Security Templates, see Best practices.
  • For help with specific tasks, see How To.
  • For general background information, see Concepts.
  • For problem-solving instructions, see Troubleshooting.
  • Other security policy tools:
Security Configuration Manager Tool | Description
Security Configuration and Analysis | You can use this tool to analyze or configure computer security using a security template.
Security Settings extension to Group Policy | You can use this tool to edit individual security settings on a domain, site, or organizational unit in Active Directory.
Local Security Policy | You can use this tool to edit individual security settings for your local computer.
Secedit | You can use this tool for automating security configuration tasks.

For more information on the individual security settings, see Security setting descriptions.


Checklist: Securing computers using Security Configuration Manager

Preparing to set up security
Step | Reference
Review security best practices. | Security best practices
Review the descriptions of individual settings. | Security setting descriptions
Review default security settings. | Default security settings, Default groups and Differences in default security settings
Have Users only use applications belonging to the Windows Logo Program for Software. | Applications that belong to the Windows Logo Program for Software are guaranteed to run for members of the Users group. For other applications to run, you might need to elevate the privileges of your users to Power Users or relax the User permissions security settings. Both are less secure configurations for your organization. For more information, see the Windows Logo Program for Software page at the Microsoft Web site (http://www.microsoft.com/).
Analyze your current settings
Step | Reference
Review Security Templates. | Security Templates
Select a predefined security template or create a new security template to use for your computers. | Predefined security templates or To define a new security template
Perform a security analysis on the computer. | Analyze system security
Modify security settings
Step | Reference
Apply the appropriate template. | To apply a security template to local policy or To import a security template to a Group Policy object
(Optional) Modify security settings on your local computer | To edit local security settings
(Optional) Modify security settings for a domain or organizational unit. | To edit a security setting on a Group Policy object


Best practices for Security Templates

Use templates properly

  • Do not apply predefined or newly-created security templates to your computer or network without testing to ensure that the right level of application functionality is maintained.
  • Never edit the Setup security.inf template, since it gives you the option to reapply the default security settings. If you ever remove a security template from a Group Policy object, appropriately reapply the Setup security.inf to restore all default settings.
  • Do not apply the Setup security.inf template through Group Policy. The Setup security.inf template should only be applied to the local computer through Secedit or Security Configuration and Analysis. It is preferable to apply it in parts using the Secedit command-line tool.

    For more information, see Automating security configuration tasks.

  • Do not apply the Compatible template to domain controllers. For example, do not import the Compatible template to the Default Domain or Default Domain Controller Group Policy object.

Use caution when modifying predefined templates

  • Instead of modifying a predefined template, customize the predefined template and then save the changes under a different template name. Since these templates were designed for specific needs, having the original template will always give you the option of using it.

    For more information, see Predefined security templates.

Choose the appropriate default level of computer access

  • When deciding on the default level of computer access that end users will have, the determining factor is the installed base of applications that need to be supported. If users only use applications that belong to the Windows Logo Program for Software, then you can make all your end users members of the Users group. If not, you may have to make your end users part of the Power users group so that they have the appropriate privileges to use the application, which is less secure.

    For more information about the Windows Logo Program for Software, see the Windows Logo Program for Software page at the Microsoft Web site. (http://www.microsoft.com/)

For more information, see Best practices for Security Configuration and Analysis and Best practices for Security Settings on a Group Policy object.


How to...

Microsoft Windows graphic

How to ...

  • Add Security Templates to an MMC console
  • Customize a predefined security template
  • Define a security template
  • Set a new security template path
  • Create a Restricted Groups policy
  • Apply a security template to a local computer
  • Import a security template to a Group Policy object


Add Security Templates to an MMC console

Microsoft Windows graphic

To add Security Templates to an MMC console

  1. Click Start, click Run, then type mmc, then click OK.
  2. (Optional) To open an existing console, on the File menu, click Open, click the console you want to open, and then click Open.
  3. On the File menu, click Add/Remove Snap-in.
  4. In Add/Remove Snap-in, click Add.
  5. In Available Standalone Snap-ins, click Security Templates, click Add, click Close, and then click OK.
  6. On the File menu, click Save.

Note

  • XOX

Related Topics


Customize a predefined security template

Microsoft Windows graphic

To customize a predefined security template

  1. Open Security Templates.
  2. In the console tree, double-click the default path folder (systemroot\Security\Templates), and in the details pane, right-click the predefined template you want to modify.
  3. Click Save As, type a new file name for the security template, and click Save.
  4. In the console tree, double-click the new security template to display the security policies, and navigate until the security attribute you want to modify appears in the details pane.
  5. In the details pane, right-click the security attribute and click Properties.
  6. Select the Define this policy setting in the template check box, make your changes, then click OK.

Notes

  • XOX
  • To open Security Templates, click Start, and click Run, then type mmc and click OK. On the File menu, click Open, click the console that you want to open, then click Open. Then, in the console tree, click Security Templates.
  • Only administrators have the permissions to make any changes to the default security template folder, which is:

    systemroot\Security\Templates

Related Topics


Define a security template

Microsoft Windows graphic

To define a security template

  1. Open Security Templates.
  2. Right-click the folder where you want to store the new template and click New Template.
  3. In Template name, type the name for your new security template.
  4. In Description, type a description of your new security template, and then click OK.
  5. In the console tree, double-click the new security template to display the security areas and navigate until the security setting you want to configure is in the details pane.
  6. In the details pane, right-click the security setting you want to configure and click Properties.
  7. Select the Define this policy setting in the template check box, edit the settings, and then click OK.

Notes

  • XOX
  • To open Security Templates, click Start, click Run, type mmc, and then click OK. On the File menu, click Open, click the console that you want to open, then click Open. In the console tree, click Security Templates.
  • Only administrators have the permissions to make any changes to the default security template folder, which is:

    systemroot\Security\Templates

    If you would like to create a new folder for new security templates, see To set a new security template path.
  • For more information on the different policy settings, see Security setting descriptions.

Related Topics


Set a new security template path

Microsoft Windows graphic

To set a new security template path

  1. Open Security Templates.
  2. In the console tree, right-click Security Templates, click New Template Search Path, and select the new location.

    3. A folder with the path of the new location appears in the console tree.

  3. (Optional) To add a description to the new template path (in addition to the name), in the console tree, right-click the new template folder, click Set Description, and then type the description you want to add.

Notes

  • XOX
  • To open Security Templates, click Start, and click Run, then type mmc and click OK. On the File menu, click Open, click the MMC console that you want to open, then click Open. Then, in the console tree, click Security Templates.

Related Topics


Create a Restricted Groups policy in a security template

Microsoft Windows graphic

To create a Restricted Groups policy in a security template

  1. Open Security Templates.
  2. In the console tree, click Restricted Groups.

    Where?

    • Security Templates
    • Template path folder
    • Security template
    • Restricted Groups
  3. In the console tree, right-click Restricted Groups, and then click Add Group.
  4. In Group, type the name of the new or existing group for which you would like restricted policy and click OK.
  5. To add members to the group, do one of the following:
    • If you created a new group, click Add Members
    • If you are working with an existing group, in the details pane, right-click the group you added, click Properties, and then click Add Members.
  6. In NewGroup Properties, click Add Members, and then type the member you would like to add. Repeat this step for each member you would like to add.
  7. To add this group as a member of any other groups, in NewGroup Properties, click Add Groups, type the name of the group, and click OK. Repeat this step for each group you want to add.

Important

  • If Restricted Groups policy is defined for the Administrators group, when the template is imported to a Group Policy object or applied to your local computer, then all members not defined in the policy will be removed from the Administrators group.

Notes

  • XOX
  • To open Security Templates, click Start, and click Run, then type mmc and click OK. On the File menu, click Open, click the console that you want to open, then click Open. Then, in the console tree, click Security Templates.
  • Restricted Groups policy states that only the members that you have added can belong to that group. When the security template is used to configure your local computer, during the configuration, only members specified in Restricted Groups policy will remain members. Similarly, at the time of configuration, if the member does not belong to the group, they will be added to the group.
  • If there are no users in a defined restricted group, then all current members of that group are removed when you apply or import the template.
  • To copy all of the restricted group entries from one template to another, in the console tree, right-click Restricted Groups, click Copy, right-click Restricted Groups in the other template, and then click Paste.

Related Topics


Apply a security template to local policy

Microsoft Windows graphic

To apply a security template to local policy

  1. Open Security Configuration and Analysis.
  2. In the console tree, right-click Security Configuration and Analysis, and then click Open Database.

    Where?

    • ConsoleRoot
    • Security Configuration and Analysis
  3. In File name, type a file name and then click Open.
  4. (Optional) If you are creating a new policy, in Import Template, do one of the following:
    • To clear the database of any previously imported templates, select the Clear this database before importing check box.
    • To append this template to any previously imported templates, confirm that the Clear this database before importing check box is cleared. (The last template that was imported has precedence over any conflicting values.)
  5. In Import Template, click a template, and then click Open.
  6. In the console tree, right-click Security Configuration and Analysis, and then click Configure Computer Now.
  7. Do one of the following:
    • To use the default error log, in Error log file path, click OK.
    • To specify a different error log, in Error log file path, type a valid path and file name.

Notes

  • XOX
  • To open Security Configuration and Analysis, click Start, and click Run, then type mmc and click OK. On the File menu, click Open, click the console that you want to open, and then click Open. Then, in the console tree, click Security Configuration and Analysis.
  • To check the log file, right click Security Configuration and Analysis, and then click View Log File.
  • The default path for the log file is:

    systemroot\Documents and Settings\UserAccount\My Documents\Security\Logs\

  • The security settings on the local computer take effect immediately.
  • To import more than one template to your computer policy, see To import a security template.
  • If you import more than one template, the database will merge the various templates to create one composite template, resolving conflicts in order of import. The last template that is imported takes precedence over any conflicting settings.

Related Topics


Import a security template to a Group Policy object

Microsoft Windows graphic

To import a security template to a Group Policy object

  1. Perform one of these steps
    2. If Do this
    You are on a workstation or server which is joined to a domain and you would like to import a security template for a Group Policy object.
    • Click Start, point to Run, type mmc and click OK.
    • On the File menu, click Add/Remove snap-in.
    • In Add/Remove Snap-in, click Add, in Add Standalone Snap-in, double-click Group Policy Object Editor.
    • In Select Group Policy Object, click Browse, select the policy object you would like to modify, click OK, and then click Finish.
    • Click Close and then click OK.
    You are on a domain controller and you would like to import a security template for a domain or organizational unit.
    • Open Active Directory Users and Computers.
    • In the console tree, right-click the domain or organizational unit you want to set Group Policy for.
    • Click Properties, and then click the Group Policy tab.
    • Click Edit to open the Group Policy object you want to edit or click New to create a new Group Policy object, and then click Edit.
  2. In the Group Policy console tree, right-click Security Settings.

    3. Where?

    • Group Policy Object Policy
    • Computer Configuration
    • Windows Settings
    • Security Settings
  3. Click Import Policy, click the security template you want to import, and then click Open.
  4. (Optional) If you want to clear the database of any previously stored security templates, select the Clear this database before importing check box.

Notes

  • XOX
  • XOX
  • Do not import Setup security.inf to a Group Policy object.
  • XOX

Related Topics


Concepts

This section provides general background information on using Security Templates to manage system security:

  • Security Templates overview
  • Predefined security templates
  • Understanding Security Templates
  • Resources


Security Templates overview

With the Security Templates snap-in for Microsoft Management Console, you can create a security policy for your computer or for your network. It is a single point of entry where the full range of system security can be taken into account. The Security Templates snap-in does not introduce new security parameters, it simply organizes all existing security attributes into one place to ease security administration.

Importing a security template to a Group Policy object eases domain administration by configuring security for a domain or organizational unit at once. For more information, see To import a security template to a Group Policy object.

In order to apply a security template to your local computer, you can use Security configuration and analysis or the Secedit command-line tool. For more information, see To configure local computer security.

Security templates can be used to define:

  • Account Policies
    • Password Policy
    • Account Lockout Policy
    • Kerberos Policy
  • Local Policies
    • Audit Policy
    • User Rights Assignment
    • Security Options
  • Event Log: Application, system, and security Event Log settings
  • Restricted Groups: Membership of security-sensitive groups
  • System Services: Startup and permissions for system services
  • Registry: Permissions for registry keys
  • File System: Permissions for folders and files

Each template is saved as a text-based .inf file. This enables you to copy, paste, import, or export some or all of the template attributes. With the exceptions of Internet Protocol security and public key policies, all security attributes can be contained in a security template.

New and predefined templates

With each member of the Microsoft® Windows® Server 2003 family or with the XOX operating system, there are a set of predefined templates created for different levels of security to suit your organization.

There are several predefined templates that can help you to secure your system based on your needs, these templates are for:

  • Reapplying default settings.
  • Implementing a highly secure environment.
  • Implementing a less secure but more compatible environment.
  • Securing the systemroot.

For more information, see Predefined security templates.

The Setup security.inf template allows you to reapply default security settings. This template is created during setup for each computer and must be applied locally.

You can create a new security template with your own preferences or use one of the predefined security templates. Before making any changes to your security settings you should understand what the default settings of your system are and what they mean.

For more information about Security Templates, see Security Templates.


Predefined security templates

The predefined security templates are provided as a starting point for creating security policies that are customized to meet different organizational requirements. You can customize the templates with the Security Templates snap-in. Once you customize the predefined security templates, you can use them to configure security on an individual computer or thousands of computers. You can configure individual computers with the Security Configuration and Analysis snap-in, the Secedit command-line tool, or by importing the template into Local Security Policy. You can configure multiple machines by importing a template into Security Settings, which is an extension to Group Policy. You can also use a security template as a baseline for analyzing a system for potential security holes or policy violations by using the Security Configuration and Analysis snap-in. By default, the predefined security templates are stored in:

systemroot\Security\Templates

  • Default security (Setup security.inf)

    • The Setup security.inf template is created during installation for each computer. It can vary from computer to computer, based on whether the installation was a clean installation or an upgrade. Setup security.inf represents the default security settings that are applied during installation of the operating system, including the file permissions for the root of the system drive. It can be used on servers and client computers; it cannot be applied to domain controllers. You can apply portions of this template for disaster recovery purposes.

    Setup security.inf should never be applied using Group Policy. It contains a large amount of data and can seriously degrade performance if it is applied through Group Policy, because policy is periodically refreshed and a large amount of data would move through the domain.

    It is advisable to apply the Setup security.inf template in parts. Since the Secedit command-line tool gives you this option, it is advisable to use it.

    For more information, see Automating security configuration tasks.

  • Domain controller default security (DC security.inf)

    • This template is created when a server is promoted to a domain controller. It reflects file, registry, and system service default security settings. Reapplying it resets these areas to the default values, but it may overwrite permissions on new files, registry keys and system services created by other applications. It can be applied using the Security Configuration and Analysis snap-in or the Secedit command-line tool.

  • Compatible (Compatws.inf)

    • Default permissions for workstations and servers are primarily granted to three local groups: Administrators, Power Users, and Users. Administrators have the most privileges while Users have the least. Because of this, you can significantly improve the security, reliability, and total cost of system ownership by:

    • Making sure that end users are members of the Users group.
    • Deploying applications that can be run successfully by members of the Users group.

    People with User privileges can successfully run applications that take part in the Windows Logo Program for Software. However, Users may not be able to run applications that do not meet the requirements of the program. If other applications must be supported, there are two options:

    • Allow members of the Users group to be members of the Power Users group.
    • Relax the default permissions that are granted to the Users group.

    Since Power Users have inherent capabilities, such as creating users, groups, printers, and shares, some administrators would rather relax the default User permissions than allow end users to be members of the Power Users group. This is precisely what the Compatible template is for. The Compatible template changes the default file and registry permissions that are granted to Users in a manner that is consistent with the requirements of most applications that do not belong to the Windows Logo Program for Software. Additionally, since it is assumed that the administrator that is applying the Compatible template does not want end users to be Power Users, the Compatible template also removes all members of the Power Users group. For more information, see Default security settings.

    For more information on the Windows Logo Program for Software, see the Microsoft Web site (http://www.microsoft.com).

    The Compatible template should not be applied to domain controllers. For example, do not import the Compatible template to the Default Domain policy or Default Domain Controller policy.

  • Secure (Secure*.inf)

    • The Secure templates define enhanced security settings that are least likely to impact application compatibility. For example, the Secure templates define stronger password, lockout, and audit settings.

    Additionally, the Secure templates limit the use of LAN Manager and NTLM authentication protocols by configuring clients to send only NTLMv2 responses and configuring servers to refuse LAN Manager responses.

    • In order to apply Securews.inf to a member computer, all of the domain controllers that contain the accounts of all users that log on to the client must run Windows NT 4.0 Service Pack 4 or higher.
    • In order to apply Securews.inf to a member computer that is joined to a domain which contains domain controllers running Windows NT 4.0, the clocks between the domain controllers running Windows NT 4.0 and the member computers must be within 30 minutes of each other.
    • If a client is configured with Securews.inf, it will not be able to connect to servers that only use the LAN Manager authentication protocol or that run Windows NT 4.0 prior to Service Pack 4 using a local account defined on the target server.
    • If a client is configured with Securews.inf, it will not be able to connect to servers running Windows 2000 or Windows NT 4.0 using a local account defined on the target server unless the clock on the target server is within 30 minutes of the clock on the client.
    • If a client is configured with Securews.inf, it will not be able to connect to a computer running XOX or above using a local account defined on the target server unless the clock on the target server is within 20 hours of the clock on the client.
    • If a client is configured with Securews.inf, then it will not be able to connect to servers running LAN Manager that are running in share-level security mode.
    • If a server is configured with Securews.inf, then a user with a local account on that server will not be able to connect to it from a client computer running only LAN Manager that is using that local account.
    • If a server running Windows 2000 is configured with securews.inf, then a client with a local account on that server that is also configured to use NTLMv2 authentication will not be able to connect unless the clocks on the two machines are within 30 minutes of each other.
    • If a server running XOX is configured with securews.inf, then a client with a local account on that server that is also configured to use NTLMv2 authentication will not be able to connect unless the clocks on the two machines are within 20 hours of each other.
    • If a domain controller is configured with Securedc.inf, then a user with an account in that domain will not be able to connect to any member server from a client computer running only LAN Manager using that domain account.
    • Computers that run LAN Manager include Windows for Workgroups as well as Windows 95 and Windows 98 platforms that do not have the Active Directory Client Extensions Pack installed. If the Active Directory Client Extensions Pack is installed on Windows 95 or Windows 98, then those clients will be able to use NTLMv2. Windows Millennium Edition supports NTLMv2 without additional modification.
    • Computers that run Windows NT Service Pack 4 or higher can be configured to send only NTLMv2 responses by setting HKLM\System\CurrentControlSet\Control\LSA\LMCompatibilityLevel to equal 3 or higher.
    • Computers that run Windows NT Service Pack 4 or higher can be configured to send only NTLMv2 responses by specifying this preference in the Network security: LAN Manager Authentication Level security option.

    The Secure templates also provide further restrictions for anonymous users by preventing anonymous users (such as users from untrusted domains) from:

    • Enumerating account names and shares.
    • Performing SID-to-name or name-to-SID translations.

    Finally, the Secure templates enable server-side Server Message Block (SMB) packet signing, which is disabled by default for servers. Since client-side SMB packet signing is enabled by default, SMB packet signing will always be negotiated when workstations and servers are operating at the Secure level.

  • Highly Secure (hisec*.inf)

    • The Highly Secure templates are supersets of the secure templates that impose further restrictions on the levels of encryption and signing that are required for authentication and for the data that flows over secure channels and between SMB clients and servers. For example, while the Secure templates cause servers to refuse LAN Manager responses, the Highly Secure templates cause servers to refuse both LAN Manager and NTLM responses. While the Secure template enables server-side SMB packet signing, the Highly Secure template requires it. Additionally, the Highly Secure templates require strong encryption and signing for the secure channel data that constitutes domain-to-member and domain-to-domain trust relationships. relationships. Thus, in order to apply hisecws.inf to a member machine:

    • All of the domain controllers that contain the accounts of all users that will logon to the client must be running Windows NT 4.0 Service Pack 4 or higher.
    • All of the domain controllers for the domain that the client is joined to must run Windows 2000 or later.

    • Clients that are configured with Hisecws.inf cannot connect to computers that only run LAN Manager or computers running Windows NT 4.0, Service Pack 3 or earlier using a local account defined on the target server.
    • Clients that are configured with Hisecws.inf cannot connect to servers running Windows 2000 or Windows NT 4.0 Service Pack 4 using a local account defined on the target server unless the clock on the target server is within 30 minutes of the clock on the client.
    • Clients that are configured with Hisecws.inf cannot connect to computers running XOX or above using a local account defined on the target computer unless the clock on the target computer is within 20 hours of the clock on the client.
    • Clients that are configured with Hisecws.inf cannot connect to LAN Manager servers operating in share-level security mode.
    • In order to apply Hisecdc.inf to a domain controller, all of the domain controllers in all trusted or trusting domains must run Windows 2000 or Windows Server 2003 family operating systems.
    • If a server is configured with Hisecws.inf, then a user with a local account on that server will not be able to connect to it from a client that does not support NTLMv2.
    • If a server is configured with Hisecws.inf, then a client with a local account on that server will not be able to connect to the server unless the client's computer is configured to send NTLMv2 responses.
    • If a server is configured with Hisecws.inf, then all clients that want to use SMB to connect to that server must enable client-side SMB packet signing. All computers running Windows 2000 and XOX operating systems enable client-side SMB packet signing by default.
    • If a domain controller is configured with Hisecdc.inf, then a user with an account in that domain cannot connect to member servers using that domain user account if the connection is being attempted from a client that only uses the LAN Manager authentication protocol.
    • If a domain controller is configured with Hisecdc.inf, then a user with an account in that domain will not be able to connect to member servers using that domain account unless:
      • Both the client and target server are running Windows 2000 or above and can use Kerberos-based authentication rather than LAN Manager-based authentication.
      • The client is configured to send NTLMv2 responses.
    • If a domain controller is configured with Hisecdc.inf, then Lightweight Directory Access Protocol (LDAP) clients will not be able to bind with the Active Directory LDAP server unless data signing is negotiated. BIND requests using ldap_simple_bind or ldap_simple_bind_s are rejected. By default, all Microsoft LDAP clients that ship with XOX will request data signing if Transport Layer Security/Secure Sockets Layer (TLS/SSL) is not already being used. If TLS/SSL is being used, then data signing is considered to be negotiated.
    • Clients that do not support NTLMv2 include Windows for Workgroups, Windows NT clients prior to Service Pack 4, and Windows 95 and Windows 98 platforms that do not have the Active Directory Client Extensions Pack installed.
    • Computers that run Windows NT Service Pack 4 or higher can be configured to send only NTLMv2 responses by setting HKLM\System\CurrentControlSet\Control\LSA\LMCompatibilityLevel=3 or higher.
    • Computers that run Windows 2000 or higher can be configured to send only NTLMv2 responses by specifying this preference in the Network security: LAN Manager Authentication Level security option.

    In addition to further restrictions on the use of LAN Manager protocols and the requirements for encryption and signing of secure channel and SMB traffic, the Highly Secure templates also limit the use of cached logon data, such as data stored by Winlogon and Stored User Names and Passwords.

    Finally, Hisecws.inf uses restricted group settings to:

    • Remove all members of the Power Users group.
    • Ensure that only Domain Admins and the local Administrator account are members of the local Administrators group.
    Hisecws.inf defines these group restrictions under the assumption that users only use applications that belong to the Windows Logo Program for Software. With those applications in place, neither the insecure Compatible template nor the insecure Power Users group is needed. Instead, users can run those applications successfully under the secure context of a normal member of the Users group, which is defined by the default security settings of the file system and registry. Members of the Administrators group can still use any application that they want.

    For information about the Windows Logo Program for Software, see the Windows Logo Program for Software page at the Microsoft Web site (http://www.microsoft.com/).

  • System root security (Rootsec.inf)

    • Rootsec.inf specifies the root permissions. By default, Rootsec.inf defines these permissions for the root of the system drive. This template can be used to reapply the root directory permissions if they are inadvertently changed, or the template can be modified to apply the same root permissions to other volumes. As specified, the template does not overwrite explicit permissions that are defined on child objects; it propagates only the permissions that are inherited by child objects.

  • No Terminal Server user SID (Notssid.inf)

    • The default file system and registry access control lists that are on servers grant permissions to a Terminal Server security identifier (SID). The Terminal Server SID is used only when Terminal Server is running in application compatibility mode. If Terminal Server is not being used, this template can be applied to remove the unnecessary Terminal Server SIDs from the file system and registry locations. However, removing the access control entry for the Terminal Server SID from these default file system and registry locations does not increase the security of the system. Instead of removing the Terminal Server SID, simply run Terminal Server in Full Security mode. When running in Full Security mode, the Terminal Server SID is not used.

Caution

  • These security templates are constructed with the assumption that they will be applied to computers that use the default security settings. In other words, these templates incrementally modify the default security settings, if they are on the computer. They do not install the default security settings before performing the modifications.
  • Predefined security templates should not be applied to production systems without testing to ensure that the right level of application functionality is maintained for your network and system architecture.

Security template settings can be viewed through Security Templates. The *.inf files can also be viewed as text files. These files are located in:

%windir%\Security\Templates

You cannot secure XOX systems that are installed on file allocation table (FAT) file systems.

For more information, see To customize a predefined security template, To import a security template to a Group Policy object, To configure local computer security, and To reapply default security settings.


Understanding Security Templates

Security Templates enables you to define file representations of a security policy. You can configure security for:

  • Account and local policies
  • Event log
  • Security settings for file system, registry, system services


Account and local policies

All security policies are computer-based policies. This section explains account policies and local policies.

Account policies

Account policies are defined on computers, yet they affect how user accounts can interact with the computer or domain. Account policies contain three subsets:

  • Password policy. Used for domain or local user accounts. Determines settings for passwords, such as enforcement and lifetimes.
  • Account lockout policy. Used for domain or local user accounts. Determines the circumstances and length of time that an account will be locked out of the system.
  • Kerberos policy. Used for domain user accounts. Determines Kerberos-related settings, such as ticket lifetimes and enforcement. Kerberos policies do not exist in Local Computer Policy.

For domain accounts, there can be only one account policy. The account policy must be defined in the Default Domain policy and is enforced by the domain controllers that make up the domain. A domain controller always obtains the account policy from the Default Domain Policy Group Policy object, even if there is a different account policy applied to the organizational unit that contains the domain controller. By default, workstations and servers joined to a domain (such as member computers) will also receive the same account policy for their local accounts. However, local account policies can be different from the domain account policy, such as when you define an account policy specifically for the local accounts.

There are two policies in Security Options that also behave like account policies. These are:

  • Network Access: Allow anonymous SID/NAME translation
  • Network Security: Force Logoff when Logon Hours expire

Local policies

These policies apply to a computer and contain these subsets:

  • Auditing policy. Determines whether security events are logged into the Security log on the computer. Also determines whether to log successful attempts, failed attempts or both. (The Security log is part of Event Viewer.)
  • User rights assignment. Determines which users or groups have logon rights or privileges on the computer.
  • Security options. Enables or disables security settings for the computer, such as digital signing of data, Administrator and Guest account names, floppy drive and CD-ROM access, driver installation, and logon prompts.

Because a computer can have more than one policy applied to it, there can be conflicts in security policy settings. The order of precedence from highest precedence to lowest precedence is organizational unit, domain, and local computer. For more information, see Applying security settings through Group Policy.


Event log security settings

This security area defines attributes that are related to the application, security, and system logs: maximum log size, access rights for each log, and retention settings and methods. The application log records events generated by programs; the security log records security events, including logon attempts, object access, and changes to security, depending on what is audited; and the system log records operating system events. For more information, see Event Viewer.

For more information on event log policies, see Settings for Event Logs.


Security settings for file system, registry, and system services

File system and registry keys

You can configure security attributes using Security Configuration Manager for all existing files, folders, and registry keys in the local file system:

  • Propagate inheritable permissions to all subfolders and files (or subkeys): Any child objects of this object inherit the parental object's security. provided the child object is not protected from inheritance. If there is a conflict, the explicit permissions on the child object will override the permissions inherited from the parent object.
  • Replace existing permissions on all subfolders and files (or subkeys) with inheritable permissions: The parent object's permission entries will override any security settings on the child object, regardless of the child object's settings. The child object will have identical Access Control Entries as the parent object.

    Caution

    • If you select this option and then click Apply, you will override all child objects' security settings. You will not be able to reset the child objects' security settings by clearing the check box.
  • Do not allow permissions on this file or folder (or key) to be replaced: Use this setting if you do not want to configure or analyze security for this object or any of its child objects.

System services

You can select this if the startup mode is:
  • Automatic: Automatically starts when computer is restarted.
  • Manual: Does not start unless someone starts it.
  • Disabled: The service cannot be started.

Notes

  • You can also edit the security properties of the object: what user or group accounts have permission to read, write, delete, or execute inheritance settings or auditing and ownership permission by clicking Edit Security
  • If you choose to set system service startup to Automatic, perform adequate testing to verify that the services can start without user intervention.
  • You should track the system services used on a computer. For performance optimization, set unnecessary or unused services to Manual.

For more information on file and folder permissions, see Permissions for files and folders.


Troubleshooting

What problem are you having?

The security database is corrupted.

Cause: Improperly shutting down the computer or a software error.

Solution: At a command prompt, run esentutl /g to check the integrity of the security database at %windir%\Security\Database\Secedit.sdb.

If the database is corrupt:

  1. Attempt to recover it by typing esentutl /r at a command prompt on the %windir%\Security folder. If this fails, attempt to repair it by typing esentutl /p at a command prompt on %windir%\Security\Database\Secedit.sdb.
  2. After that, delete the log files in %windir%\Security.

Security policy is not propagating correctly.

Cause: Multiple.

Solution: Use Resultant Set of Policy to check what Group Policy object is affecting your computer.

Check the log file. The log file is located in systemroot\Security\Logs\Winlogon.log. You can examine this log file to identify specific errors that occur during policy propagation to the computer.

Security policies are propagated with the following warning: 0x534 : No mapping between account names and security IDs was done.

Cause: This is usually caused because the security policy grants rights to user or group accounts which no longer exist.

Solution: Find out which accounts are invalid.

  1. Open Notepad and open the file at %systemroot%\security\logs\winlogon.log. Members of the Windows Server 2003 family and computers running XOX create this file by default during policy propagation.
  2. Search for error 1332. This indicates the account names that could not be resolved.
  3. Remove the unresolved account names from policies in your domain.

If the accounts are in the Default Domain or Domain Controller Group Policy objects, you can edit the policies in the Security Settings node of Group Policy to remove these account names. If the accounts exist elsewhere, you may have to browse through all Group Policy objects that are defined in the domain and remove them individually.

You receive the following error message: The system cannot log you on now because the domain <DOMAIN_NAME> is not available.

Cause: The domain controller is unavailable and a user's logon information is not being cached. The Interactive logon: Number of previous logons to cache (in case domain controller is not available) security policy is set to 0.

Solution: Edit the security policy.

See also: Interactive logon: Number of previous logons to cache (in case domain controller is not available)


Security Configuration Manager tools

You can use these tools to manage security policy on your computer, organizational unit, or domain.
Security Configuration Manager tool | Description
Security Templates | A security template is a file which represents a security configuration or security policy. These templates can then be applied to your local computer policy or imported to a Group Policy object.
Security Configuration and Analysis | You can use this tool to analyze or configure computer security using a security template.
Security Settings extension to Group Policy | You can use this tool to edit individual security settings on a domain, site, or organizational unit.
Local Security Policy | You can use this tool to edit individual security settings for your local computer.
Secedit.exe (command-line tool) | You can use this tool for automating security configuration tasks.


Resources

For more information about security, see the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)

For more information about authorization and access control at the Microsoft Windows Resource Kits Web site.(http://www.microsoft.com/)

For more information about authentication, see "Logon and Authentication" at the Microsoft Windows Resource Kits Web site.(http://www.microsoft.com/)

For more information about security groups, see "Designing an Authorization Strategy" at the Microsoft Windows Resource Kits Web site.(http://www.microsoft.com/)

For the latest recommendations about security, see the Microsoft Security page on the Microsoft Web site.(http://www.microsoft.com)

For information about the Microsoft Security Notification Service, see Product Security Notification Web site. (http://www.microsoft.com/)


Using Security Templates

Security Templates offers the ability to define system security by storing system security settings in a security template, and then applying or importing that template to a system. You must have appropriate administrator rights to the appropriate Group Policy object or the local computer.

  • Predefined templates


Assigning user rights

You assign user rights by configuring user rights settings for local policies. Assigning user rights is one way that you can delegate or restrict administrative control within a domain.

For information on delegating administrative control through the assignment of user rights, see Delegating administration.

Related Topics


Logon rights

The following table lists and describes logon rights.

Logon Right Description
Access this computer from a network

This user right determines which users and groups are allowed to connect to the computer over the network. Terminal Services are not affected by this user right.

Default:

  • On workstations and servers:
    • Administrators
    • Backup Operators
    • Power Users
    • Users
    • Everyone
  • On domain controllers:
    • Administrators
    • Authenticated Users
    • Everyone
Allow log on locally

This logon right determines which users can interactively log on to this computer. Logons initiated by pressing CTRL+ALT+DEL on the attached keyboard requires the user to have this logon right. Additionally this logon right may be required by some service or administrative applications that can log on users. If you define this policy for a user or group, you must also give the Administrators group this right.

Default:

  • On workstations and servers: Administrators, Backup Operators, Power Users, Users, and Guest.
  • On domain controllers: Account Operators, Administrators, Backup Operators, Print Operators, and Server Operators.
Allow log on through Terminal Services

This security setting determines which users or groups have permission to log on as a Terminal Services client.

Default:

  • On workstation and servers: Administrators, Remote Desktop Users.
  • On domain controllers: Administrators.
Deny access to this computer from network

This security setting determines which users are prevented from accessing a computer over the network. This policy setting supersedes the Access this computer from the network policy setting if a user account is subject to both policies.

Default: No one.
Deny log on as a batch job

This security setting determines which accounts are prevented from being able to log on as a batch job. This policy setting supersedes the Log on as a batch job policy setting if a user account is subject to both policies.

Default: None.
Deny logon as a service

This security setting determines which service accounts are prevented from registering a process as a service. This policy setting supersedes the Log on as a service policy setting if an account is subject to both policies.

Note

  • This security setting does not apply to the System, Local Service, or Network Service accounts.

Default: None.
Deny log on locally

This security setting determines which users are prevented from logging on at the computer. This policy setting supersedes the Allow log on locally policy setting if an account is subject to both policies.

Important

  • If you apply this security policy to the Everyone group, no one will be able to log on locally.

Default: None.
Deny log on through Terminal Services

This security setting determines which users and groups are prohibited from logging on as a Terminal Services client.

Default: None.
Log on as a batch job

This security setting allows a user to be logged on by means of a batch-queue facility.

For example, when a user submits a job by means of the task scheduler, the task scheduler logs that user on as a batch user rather than as an interactive user.

Note

  • In Windows 2000 Server, Windows 2000 Professional, Windows Server 2003 and XOX, the Task Scheduler automatically grants this right as necessary.

Default: Local System.
Log on as a service

This security setting determines which service accounts can register a process as a service.

Default: None.

For more information, see Privileges and Security Configuration Manager Tools.

Note

  • The default settings listed above are for XOX and the Windows Server 2003 family.


Privileges

To ease the task of user account administration, you should assign privileges primarily to group accounts, rather than to individual user accounts. When you assign privileges to a group account, users are automatically assigned those privileges when they become a member of that group. This method of administering privileges is far easier than assigning individual privileges to each user account when the account is created.

The following table lists and describes the privileges that can be granted to a user.

Privilege Description
Act as part of the operating system

This user right allows a process to impersonate any user without authentication. The process can therefore gain access to the same local resources as that user.

Processes that require this privilege should use the LocalSystem account, which already includes this privilege, rather than using a separate user account with this privilege specially assigned. If your organization only uses servers that are members of the Windows Server 2003 family, you do not need to assign this privilege to your users. However, if your organization uses servers running Windows 2000 or Windows NT 4.0, you might need to assign this privilege to use applications that exchange passwords in plaintext.

Default: Local System.
Add workstations to a domain

This security setting determines which groups or users can add workstations to a domain.

This security setting is valid only on domain controllers. By default, any authenticated user has this right and can create up to 10 computer accounts in the domain.

Adding a computer account to the domain allows the computer to participate in Active Directory–based networking. For example, adding a workstation to a domain enables that workstation to recognize accounts and groups that exist in Active Directory.

Default: Authenticated Users on domain controllers.
Adjust memory quotas for a process

This privilege determines who can change the maximum memory that can be consumed by a process.

This user right is defined in the Default Domain Controller Group Policy object (GPO) and in the local security policy of workstations and servers.

Default: Administrators.
Back up files and directories

This user right determines which users can bypass file and directory, registry, and other persistent object permissions for the purposes of backing up the system.

Default: Administrators and Backup Operators.
Bypass traverse checking

This user right determines which users can traverse directory trees even though the user may not have permissions on the traversed directory. This privilege does not allow the user to list the contents of a directory, only to traverse directories.

This user right is defined in the Default Domain Controller Group Policy object (GPO) and in the local security policy of workstations and servers.

Default:

  • On workstations and servers:
    • Administrators
    • Backup Operators
    • Power Users
    • Users
    • Everyone
  • On domain controllers:
    • Administrators
    • Authenticated Users
Change the system time

This user right determines which users and groups can change the time and date on the internal clock of the computer. Users that are assigned this user right can affect the appearance of event logs. If the system time is changed, events that are logged will reflect this new time, not the actual time that the events occurred.

This user right is defined in the Default Domain Controller Group Policy object (GPO) and in the local security policy of workstations and servers.

Default:

  • On workstations and servers:
    • Administrators
    • Power Users
  • On domain controllers:
    • Administrators
    • Server Operators
Create a pagefile

Allows the user to create and change the size of a pagefile. This is done by specifying a paging file size for a particular drive under Performance Options on the Advanced tab of System Properties.

Default setting: Administrators
Create a token object

Allows a process to create a token which it can then use to get access to any local resources when the process uses NtCreateToken() or other token-creation APIs.

It is recommended that processes requiring this privilege use the LocalSystem account, which already includes this privilege, rather than using a separate user account with this privilege specially assigned

Default setting: No one
Create global objects

This security setting determines which accounts are allowed to create global objects in a terminal services session.

Default: Administrators and Local System.
Create permanent shared objects

Allows a process to create a directory object in the Windows Server 2003 family and XOX object manager. This privilege is useful to kernel-mode components that extend the object namespace. Components that are running in kernel mode already have this privilege inherently; it is not necessary to assign them the privilege.

Default setting: No one
Debug programs

This user right determines which users can attach a debugger to any process or to the kernel. Developers who are debugging their own applications to not need to be assigned this user right. Developers who are debugging new system components will need this user right to be able to do so. This user right provides complete access to sensitive and critical operating system components.

Default setting:

  • Administrators
  • Local System
Enable computer and user accounts to be trusted for delegation

This security setting determines which users can set the Trusted for Delegation setting on a user or computer object.

The user or object that is granted this privilege must have write access to the account control flags on the user or computer object. A server process running on a computer (or under a user context) that is trusted for delegation can access resources on another computer using the delegated credentials of a client, as long as the account of the client does not have the Account cannot be delegated account control flag set.

This user right is defined in the Default Domain Controller Group Policy object (GPO) and in the local security policy of workstations and servers.

Default setting: On domain controllers:

  • Administrators
Force shutdown from a remote system

This security setting determines which users are allowed to shut down a computer from a remote location on the network. Misuse of this user right can result in a denial of service.

This user right is defined in the Default Domain Controller Group Policy object (GPO) and in the local security policy of workstations and servers.

Default:

  • On workstations and servers: Administrators.
  • On domain controllers: Administrators, Server Operators.

Generate security audits

This security setting determines which accounts can be used by a process to add entries to the security log. The security log is used to trace unauthorized system access. Misuse of this user right can result in the generation of many auditing events, potentially hiding evidence of an attack or causing a denial of service if the Audit: Shut down system immediately if unable to log security audits security policy setting is enabled. For more information, see Audit: Shut down system immediately if unable to log security audits

Default: Local System.
Impersonate a client after authentication

This security setting determines which accounts are allowed to impersonate other accounts.

Default: Administrators and Service.
Increase scheduling priority

This security setting determines which accounts can use a process with Write Property access to another process to increase the execution priority assigned to the other process. A user with this privilege can change the scheduling priority of a process through the Task Manager user interface.

Default: Administrators.
Load and unload device drivers

This user right determines which users can dynamically load and unload device drivers or other code in to kernel mode. This user right does not apply to Plug and Play device drivers. It is recommended that you do not assign this privilege to other users. Instead, use the StartService() API.

Default setting: Administrators. It is recommended that you not assign this privilege to any other user. Device drivers run as trusted (or highly privileged) programs.

Lock pages in memory

This security setting determines which accounts can use a process to keep data in physical memory, which prevents the system from paging the data to virtual memory on disk. Exercising this privilege could significantly affect system performance by decreasing the amount of available random access memory (RAM).

Default: None. Certain system processes have the privilege inherently.
Manage auditing and security log

This security setting determines which users can specify object access auditing options for individual resources, such as files, Active Directory objects, and registry keys.

This security setting does not allow a user to enable file and object access auditing in general. For such auditing to be enabled, the Audit object access setting in Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policies must be configured.

You can view audited events in the security log of the Event Viewer. A user with this privilege can also view and clear the security log.

Default: Administrators.
Modify firmware environment values

This security setting determines who can modify firmware environment values. Firmware environment variables are settings stored in the nonvolatile RAM of non-x86-based computers. The effect of the setting depends on the processor.

  • On x86-based computers, the only firmware environment value that can be modified by assigning this user right is the Last Known Good Configuration setting, which should only be modified by the system.
  • On Itanium-based computers, boot information is stored in nonvolatile RAM. Users must be assigned this user right to run bootcfg.exe and to change the Default Operating System setting on Startup and Recovery in System Properties.
  • On all computers, this user right is required to install or upgrade Windows.

Default setting:

  • Administrators
  • Local System
Profile a single process

This security setting determines which users can use performance monitoring tools to monitor the performance of nonsystem processes.

Default: Administrators, Power users, Local System.
Profile system performance

This security setting determines which users can use performance monitoring tools to monitor the performance of system processes.

Default: Administrators, Local System.
Remove computer from docking station

This security setting determines whether a user can undock a portable computer from its docking station without logging on.

If this policy is enabled, the user must log on before removing the portable computer from its docking station. If this policy is disabled, the user may remove the portable computer from its docking station without logging on.

Default: Disabled.
Replace a process level token Determines which user accounts can initiate a process to replace the default token associated with a started subprocess.

This user right is defined in the Default Domain Controller Group Policy object and in the local security policy of workstations and servers.

Default setting: Local Service and Network Service.

Restore files and directories

This security setting determines which users can bypass file, directory, registry, and other persistent objects permissions when restoring backed up files and directories and determines which users can set any valid security principal as the owner of an object.

Specifically, this user right is similar to granting the following permissions to the user or group in question on all files and folders on the system:

  • Traverse Folder/Execute File
  • Write

Default:

  • Workstations and servers: Administrators, Backup Operators.
  • Domain controllers: Administrators, Backup Operators, Server Operators.
Shut down the system

This security setting determines which users who are logged on locally to the computer can shut down the operating system using the Shut Down command. Misuse of this user right can result in a denial of service.

Default:

  • Workstations: Administrators, Backup Operators, Power Users, Users.
  • Servers: Administrators, Backup Operators, Power Users.
  • Domain controllers: Account Operators, Administrators, Backup Operators, Server Operators, Print Operators.
Synchronize directory service data

This security setting determines which users and groups have the authority to synchronize all directory service data. This is also known as Active Directory synchronization.

Defaults: None.
Take ownership of files or other objects

This security setting determines which users can take ownership of any securable object in the system, including Active Directory objects, files and folders, printers, registry keys, processes, and threads.

Default setting: Administrators

Some privileges can override permissions set on an object. For example, a user logged on to a domain account as a member of the Backup Operators group has the right to perform backup operations for all domain servers. However, this requires the ability to read all files on those servers, even files on which their owners have set permissions that explicitly deny access to all users, including members of the Backup Operators group. A user right—in this case, the right to perform a backup—takes precedence over all file and directory permissions.

For more information, see Logon Rights, User Rights and Security Configuration Manager Tools.

Note

  • At a command prompt, you can type whoami /priv to see your privileges. For more information about the whoami command, see Whoami.


User rights

User rights grant specific privileges and logon rights to users and groups in your computing environment. For information on user rights, see the following:

  • Introduction to user rights
  • Privileges
  • Logon rights


User rights

Administrators can assign specific rights to group accounts or to individual user accounts. These rights authorize users to perform specific actions, such as logging on to a system interactively or backing up files and directories. User rights are different from permissions because user rights apply to user accounts, and permissions are attached to objects. For information on permissions, see How inheritance affects file and folder permissions.

User rights define capabilities at the local level. Although user rights can apply to individual user accounts, user rights are best administered on a group account basis. This ensures that a user logging on as a member of a group automatically inherits the rights associated with that group. By assigning user rights to groups rather than individual users, you simplify the task of user account administration. When users in a group all require the same user rights, you can assign the set of user rights once to the group, rather than repeatedly assigning the same set of user rights to each individual user account.

User rights that are assigned to a group are applied to all members of the group while they remain members. If a user is a member of multiple groups, the user's rights are cumulative, which means that the user has more than one set of rights. The only time that rights assigned to one group might conflict with those assigned to another is in the case of certain logon rights. In general user rights assigned to one group do not conflict with the rights assigned to another group. To remove rights from a user, the administrator simply removes the user from the group. In this case, the user no longer has the rights assigned to that group.

There are two types of user rights: privileges, such as the right to back up files and directories, and logon rights, such as the right to log on to a system locally.

For more information, see Privileges, Logon rights and Security Configuration Manager Tools.


Default security settings for groups

Before modifying any security settings, it is important to take into consideration the default settings.

There are three fundamental levels of security that are granted to users. These are granted to end users through membership in the Administrators, Power Users, or Users groups.

Administrators

The Administrators group is provided to perform computer maintenance tasks. The default permissions allotted to this group allow complete control over the entire system. As a result, only trusted personnel should be members of this group.

Power Users

Members of the Power Users group have more permissions than members of the Users group and fewer than members of the Administrators group. Power Users can perform any operating system task except tasks reserved for the Administrators group. The default permissions that are allotted to the Power Users group allow members of the Power Users group to modify computerwide settings.

When you upgrade from Windows NT 4.0, members of the Restricted Users group are automatically placed in the Power Users group to prevent backward compatibility issues with the applications that your organization used before the upgrade. Many applications used on Windows NT 4.0 required elevated permissions to run correctly. The default Windows 2000, XOX, and Windows Server 2003 family security settings for Power Users are very similar to the default security settings for Users in Windows NT 4.0. Any program that a user can run in Windows NT 4.0, a Power User can run in Windows 2000, XOX or Windows Server 2003 family.

If you do not want end users to have the elevated permissions of the Power Users group, you can make them members of the Users group and only run applications that belong to the Windows Logo Program for Software. If applications that do not belong to the Windows Logo Program for Software must be supported, then end users will need to be part of the Power Users group. For information about the Windows Logo Program for Software, see the Windows Logo Program for Software on the Microsoft Web site. (http://www.microsoft.com)

Power Users can:

  • Run legacy applications, in addition to applications for Windows 2000, XOX, or the Windows Server 2003 family that belong to the Windows Logo Program for Software.
  • Install programs that do not modify operating system files or install system services.
  • Customize systemwide resources including printers, date, time, power options, and other Control Panel resources.
  • Create and manage local user accounts and groups.
  • Stop and start system services which are not started by default.

Power Users do not have permission to add themselves to the Administrators group. Power Users do not have access to the data of other users on an NTFS volume, unless those users grant them permission.

Caution

  • Running legacy programs on Windows 2000, XOX, or a member of the Windows Server 2003 family often requires you to modify access to certain system settings. The same default permissions that allow Power Users to run legacy programs also make it possible for a Power User to gain additional privileges on the system, even complete administrative control. Therefore, it is important to deploy applications belonging to the Windows Logo Program for Software in order to achieve maximum security without sacrificing program functionality. These programs can run successfully under the Secure configuration that is provided by the Users group.
  • Since Power Users can install or modify programs, running as a Power User when connected to the Internet could make the system vulnerable to Trojan horse programs and other security risks.
Users

The Users group is the most secure, because the default permissions allotted to this group do not allow members to modify operating system settings or other users' data.

The Users group provides the most secure environment in which to run programs. On a volume formatted with the NTFS file system, the default security settings on a newly-installed system (but not on an upgraded system) are designed to prevent members of this group from compromising the integrity of the operating system and installed programs. Users cannot modify systemwide registry settings, operating system files, or program files. Users can shut down workstations but not servers. Users can create local groups, but can manage only the local groups that they created. They can run Windows 2000, XOX, or a member of the Windows Server 2003 family programs that belong to the Windows Logo Program for Software that have been installed or deployed by administrators. Users have full control over all of their own data files (stored at %userprofile%) and their own portion of the registry (located in HKEY_CURRENT_USER).

Note that user-level permissions often do not allow the user to successfully run legacy applications. To run these legacy applications, you must either loosen security to allow members of the Users group to run the applications or you must promote members of the Users group to the Power Users group. Both options decrease the security of your organization. Since members of the Users group are guaranteed to be able to run applications belonging to the Windows Logo Program for Software, it is a best practice to only use applications that belong to the Windows Logo Program for Software. For more information, see the Windows Logo Program for Software on the Microsoft Web site. (http://www.microsoft.com)

To secure a system running Windows 2000, XOX, or a member of the Windows Server 2003 family, an administrator should:

  • Make sure that end users are members of the Users group only.
  • Deploy programs that members of the Users group can run successfully, such as programs that belong to the Windows Logo Program for Software.

Users will not be able to run most programs written for versions of Windows prior to Windows 2000, because they did not support file system and registry security (such as Windows 95 and Windows 98) or shipped with other default security settings (Windows NT). If you have problems running legacy applications on newly-installed NTFS systems, then do one of the following:

  1. Install new versions of the applications that belong to the Windows Logo Program for Software.
  2. Move end users from the Users group into the Power Users group.
  3. Decrease the default security permissions for the Users group. This can be accomplished by using the Compatible security template.

The Anonymous group is no longer a member of the Everyone group

For XOX and the Windows Server 2003 family, the Anonymous group is no longer a member of the Everyone group.

When a Windows 2000 system is upgraded to XOX or the Windows Server 2003 family, resources with permission entries for the Everyone group (and not explicitly to the Anonymous Logon group) will no longer be available to Anonymous users after the upgrade. In most cases, this is an appropriate restriction on anonymous access. You may need to permit anonymous access in order to support pre-existing applications that require it. If you need to grant access to the Anonymous logon group, you should explicitly add the Anonymous Logon security group and its permissions.

However, in some situations where it might be difficult to determine and modify the permission entries on resources, you can change the Network access: Let Everyone permissions apply to anonymous users security setting.

Other groups

  • Interactive. This group contains the user who is currently logged on to the computer. During an upgrade to Windows 2000, XOX, or the Windows Server 2003 family, members of the Interactive group will also be added to the Power Users group, so that legacy applications will continue to function as they did before the upgrade.
  • Network. This group contains all users who are currently accessing the system over the network.
  • Terminal Server User. When terminal servers are installed in application serving mode, this group contains any users who are currently logged on to the system using Terminal Server. Any program that a user can run in Windows NT 4.0 will run for a Terminal Server User in Windows 2000, XOX, or a member of the Windows Server 2003 family. The default permissions that are assigned to the group were chosen to enable a Terminal Server user to run most legacy programs.

    • Caution

    • Running legacy programs in Windows 2000, XOX, or the Windows Server 2003 family requires permission to modify certain system settings. The same default permissions that allow a Terminal Server user to run legacy programs also make it possible for a Terminal Server user to gain additional privileges on the system, even complete administrative control. Applications that belong to the Windows Logo Program for Software can run successfully under the Secure configuration that is provided by the Users group. For more information, see the Microsoft Security page on the Microsoft Web site (http://www.microsoft.com).
    • Local accounts that are created on the local computer are created without passwords and are added to the Administrators group by default. If this is a concern, Security Configuration Manager allows you to control membership of the Administrators (or any other group) with the Restricted Groups policy. For more information, see Restricted Groups policy.

    When Terminal Server is installed in remote administration mode, users logged on using Terminal Server will not be members of this group.

  • Backup Operators

    Members of the Backup Operators group can back up and restore files on the computer, regardless of any permissions that protect those files. They can also log on to the computer and shut it down, but they cannot change security settings.

    Caution

    • Backing up and restoring data files and system files requires permissions to read and write those files. The same default permissions granted to Backup Operators that allow them to back up and restore files also make it possible for them to use the group's permissions for other purposes, such as reading another user's files or installing Trojan horse programs. Group Policy settings can be used to create an environment in which Backup Operators only can run a backup program. For more information, see the Microsoft Security page on the Microsoft Web site (http://www.microsoft.com).

For more information, see Default groups, Default settings for services, and Differences in default security settings, and the Security page on the Microsoft Web site (http://www.microsoft.com)


Differences in default security settings

The Anonymous Logon group is no longer a member of the Everyone group. This change will impact anonymous users attempting to access resources hosted on computers running XOX and members of the Windows Server 2003 family.

Anyone who accesses a computer and its resources through the network without an account name, password, or domain is a member of the Anonymous Logon built-in security group. In previous versions of Windows, members of the Anonymous Logon security group had access to many resources, due to membership of the Everyone group. Because Administrators did not realize that anonymous users were members of the Everyone group they might have inadvertently granted them access to resources only intended for authenticated users.

When a computer running Windows 2000 is upgraded to a member of the Windows Server 2003 family, resources with permission entries for the Everyone group (and not explicitly to the Anonymous Logon group) will no longer be available to anonymous users after the upgrade. In most cases, this is an appropriate restriction on anonymous access. you may need to permit anonymous access in order to support pre-existing applications that require it. If you need to grant access to the Anonymous logon group you should explicitly add the Anonymous Logon security group and its permissions.

However, in some situations where it might be difficult to determine and modify the permission entries on resources hosted on Windows Server 2003 family or XOX computers you can change the security setting, Network access: Let Everyone permissions apply to anonymous users.

For more information, see To edit a security setting on a Group Policy object or To edit local computer security.

Differences between Windows NT 4.0 and Windows Server 2003 family default security settings

Windows NT 4.0 provided two key groups whose membership could be controlled by the administrator: Administrators and Users. There was one group, Everyone, whose membership was controlled by the operating system or domain. Every user who was authenticated by the domain was a member of the Everyone group. If an administrator wanted stricter control of access to the computer's resources, the discretionary access control list (DACL) could be modified by removing the Everyone group.

Windows Server 2003 family provides three groups whose membership is controlled by the administrator: Users, Power Users, and Administrators. The group whose membership is controlled by the operating system or domain is Authenticated Users. It is the same as the Everyone group, except that it does not contain anonymous users or guests.

Unlike the Everyone group in Windows NT 4.0, the Authenticated Users group is not used to assign permissions. Only groups controlled by the administrator, primarily Users, Power Users, and members of the Administrators group, are used to assign permissions. The default members of each group are listed below.

Local Group | On XOX this group contains | On computers running Windows Server 2003 family this group contains
Administrators | Administrator | Administrator
Power Users | Authenticated Users | none
Users | Authenticated Users | Authenticated Users

By default, any authenticated user is a member of the Users group. Power Users have all the capabilities that Windows NT 4.0 Users had. This ensures backward compatibility with Windows NT 4.0. If an administrator wants to implement higher security on a computer, Authenticated Users should be made members of the Users group only.

When a Professional or Server computer joins a domain, the same domain groups are added to the computer that were added to a Windows NT 4.0 computer. Domain Administrators are added to the local Administrators group and Domain Users are added to the local Users group.

For information about changes to security settings on services, see Default settings for services.

For more information, see Default security settings and Default groups.